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Presentation  Outline 


CLIP  Program  Background 
CLIP  System  and  Software  Concept 
CLIP  Challenges 

Role  of  Architecture  in  RFP/contract 

Current  Acquisition  Status 

Proactive  Application  of  ATAM®  and  QAW®  to  Reduce 
Software  Acquisition  Risk 

Impact  of  Work 
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are  registered  in  the  U.S.  Patent  and  Trademark  Office  by  Carnegie  Mellon  University. 
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Common  Link  Integration  Processing 
(CLIP)  -  Background 

Cooperative  Air  Force/Navy  program 

•  Integrate  Tactical  Data  Links  (TDLs)  across 
platforms  with  a  TDL  requirement 

•  Provide  message  processing,  gateway 
functionality,  and  a  common  interface 

•  Enable  transition  of  new  and  legacy 
platforms  to  Network  Centric  Warfare  (NCW) 
environment 
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CLIP  System  Concept 
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CLIP  Software  Concept 
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Challenges 

•  Incremental  acquisition  supporting  different 
platform  integration  need  dates 

•  Developing  software  assets  which  will  be  portable 
to  the  different  platforms  using  diverse  hardware 
and  software 

•  Ability  to  forward  data  “intelligently”  from  multiple 
TDLs 

•  Integration  of  CLIP  with  other  DoD  systems  under 
development 

•  Development  of  a  common  host  interface 
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Key  DoD  5000  Acquisition  Documents 


•Acquisition  Strategy  and  Acquisition  Plan 
•System  Engineering  Plan 
•Test  and  Evaluation  Master  Plan 
•Request  for  Proposal 

-  Statement  of  Work 

-  System  Requirements  Document 

-  Sections  B,  H,  L,  and  M 

-  CDRLs  (Deliverables) 

•Timeline  to  support  acquisition  milestones 
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Current  Acquisition  Status 

CLIP  Contract: 

•  $275  Meg* 

•  In  final  phase  of  source  selection 

•  Projected  contract  award:  May  2005 

Software  architecture  related  contractual  events: 

•  QAW  to  be  conducted  in  July  2005 

•  Software  architecture  document  to  be  delivered  in 
support  of  Preliminary  Design  Review  (PDR) 

•  First  ATAM  engagement  in  Nov  2005 

*Source:  FCW.COM  News  Article: 

http://www.fcw.com/fcw/articles/2005/02Q7/web-comlink-02-08-05.asp 
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Software  Engineering  Institute 

Use  of  QAW  and  ATAM  to  Reduce 
Software  Acquisition  Risk 

QAW  —  Quality  Attribute  Workshop 

•  Provide  a  common  forum  for  discussing  quality 
attribute  requirements  and  architectural  implications 

•  Gain  stakeholder  buy-in 

ATAM  —  Architecture  Tradeoff  and  Analysis  Method 

•  Increase  communication  among  stakeholders 

•  Clarify  quality  attribute  requirements 

•  Identify  software  risks  early  in  the  development  cycle 

•  Provide  documented  basis  for  architectural  decisions 
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“Big  Picture”  Development  Context 


Such  a  “big  picture”  view  of  a  contractor’s  architecture-centric  development 
approach  would  be  described  in  its  Software  Development  Han  (SDP). 


©  2005  by  Carnegie  Mellon  University 


page  10 


CwKgleMdhsi 

Software  Engineering  Institute 

Software  Architecture  Evaluation  in  an 
Acquisition  Environment 

Software  architecture  evaluation  is  especially  critical  when 
acquiring  large,  complex  systems  ... 

but,  conducting  a  software  architecture  evaluation  in  the 
DoD  acquisition  environment  is  more  involved  ... 

•  acquisition  focus  is  on  acquiring  “systems” 

•  limited  points  of  contact  and  leverage 

-  exercised  from  a  distance 

-  occur  at  discrete  points  in  the  life  cycle 

-  governed  by  a  stringent  set  of  regulations 

•  lack  of  awareness  that  certain  practices  are  permitted 
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Approaches  for  Conducting 
ATAM-Based  Evaluations 

Reactive 

Software  architecture  evaluations  are  conducted 
opportunistically  and  performed  in  situ  under  an  existing 
contract  at  the  request  of  the  program  manager.1 

Proactive 

Software  architecture  evaluations  are  preplanned  and 
integrated  up  front  in  a  request  for  proposal  (RFP)  for  a 
system  (or  software)  acquisition. 


1  Or  at  the  request  of  a  contractor  under  a  separate  agreement 
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Request  for  Proposal  (RFP) 

Incorporating  architecture  evaluations  in  an  RFP  requires 
developing  appropriate  language  for  the  following  sections: 


Section  C 


Section  H 


Description,  Statement  of  Work  (SOW), 

Performance  Specification 

◄—  Special  Contract  Requirements 

(in  certain  cases) 

Contract  Deliverables  Requirements  List 

Section  L 


Instructions,  Conditions,  and  Notices 


Section  J 


to  Offerors 

Evaluation  Factors  for  Award 


©  2005  by  Carnegie  Mellon  University 


page  13 


Software  Engineering  Institute 


Government  Specifies  the  Method 

“An  evaluation  team  shall  conduct  a  series 
of  software  architecture  evaluations  in 
accordance  with  the  special  requirements 
of  Section  H.”  j  — 

Includes  detailed  requirements  (comparable 
to  a  plan)  specifying  how  the  software 
architecture  evaluations  are  to  be 
conducted  using  the  ATAM.  These  constitute 
the  software  architecture  evaluation  requirements. 

Identifies  Associated  Contract  Deliverables 

•  Software  Architecture  Documentation 

•  Software  Architecture  Evaluation  Report 
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What  Needs  to  be  Specified? 


Developing  a 
.coherent  approach 
is  nontrivial. 


Example 
on  next 
slide 


The  software  architecture  evaluation  requirements  must  address 

What  evaluation  method  is  to  be  used  and  what  are  the  steps? 

Who  are  the  participants  in  the  architecture  evaluation? 

What  are  their  roles  and  responsibilities?  _ 

How  many  evaluations  need  to  be  conducted  and  when? 

If  multiple  evaluations  are  involved,  how  are  they  to  be  staged? 

What  are  the  prerequisites  for  conducting  the  evaluations? 

What  is  involved  in  terms  of  time,  effort,  and  cost? 

How  are  evaluation  team  responsibilities  to  be  transitioned? 

How  will  the  objectivity  of  the  participants  be  ensured? 

How  are  the  evaluation  results  to  be  captured  and  used? 

What  contract  deliverables  need  to  be  included? 

How  can  the  evaluations  be  carried  out  collaboratively  to  ensure  both 
government  and  contractor  stakeholders  play  an  active  role? 

What  training  will  be  provided  for  the  evaluation  team  members? 

And  the  list  goes  on  ... 
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Participants  in  the  Initial  Architecture  Evaluation 


CLIP  Contractor’s  Software  Development  Cycle 

ATAM 

Participants 

1st  Architecture 
Evaluation 

(Iroerrent/Spiral  1) 

ATAM 

Evaluation 

Team 

SB  conducts  full 
ATAM  evaluation. 

A  contractor  and 
program  office 
representative  may 
also  attend  as 
observers. 

Project 

Decision 

Makers 

Indudes  chief 
architect  and  other 
agents  cf  contractor 
and  progamoffice 

Software 

Architecture 

Stakeholders 

(Only  participate  in 

Phase  2  of  the 

ATAM) 

Indudes  program 
office  agerts, 
contractor 
personnel,  and 
representatives 
from  organizations 
to  be  supported  by 

1  ncrerrert/Spi  ral  1 

*  External  evaluators  can  be  an  agent  of  the  government  program offi ce  or  an  agent  of  the  contractor  organization; 
contractor  agents,  though,  must  be  external  to  the  project  whose  architecture  is  being  evaluated. 
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Example  Staging  &  Transitioning  of  Responsibilities 


Contractor’s  Software  Development  Cycle 


ATAM 

Participants 


1st  Architecture 
Evaluation 

(Iroerrent/Spiral  1) 


2nd  Architecture 
Evaluation 

(Increment/Spiral  1) 


3rd  Architecture 
Evaluation 

(Inoorert/Spiral  2) 


Follow-On 

Evaluations 

(Increrrent/Spiral  3  to  N) 


ATAM 

Evaluation 

Team 


SB  conducts  full 
ATAM  evaluation. 

A  contract*, 
program  oi 
representative 
also  attend  as 
observers. 


SB  provides  ATAM 
facilitation.  Team 


SB  provides  ATAM 
coaching  only. 

evaluator  and 
team  members 
ar w  all  external  * 

'AM  evaluators. 


Project 

Decision 

Makers 


Indudes  chief 
architect  and  other 
agents  of  contractor 
and  progamcffice 


SB  is  not  involved. 

An  all  project  team 
conducts  evaluations. 
Lead  evaluator  and 
other  team  members 
are  all  external* 
ATAM  evaluators. 


Software 

Architecture 

Stakeholders 

(Only  participate  in 
Phase  2  cf  the 
ATAM) 


Indudes  program 
office  agerts, 
contractor 
personnel,  and 
representatives 
from  organizations 
to  be  supported  by 
I  ncremert/Spi  ral  1 


Alternatively, 
_  the  architecture 
evaluations  can 
be  conducted  by 
SEI  ATAM-certified 
evaluators. 


Incnsrrenl/Spiral  1 


Irxirerrert/Spiral  3 boN 


*  External  evaluators  can  be  an  agent  of  the  government  program offi ce  or  an  agent  of  the  contractor  organization; 
contractor  agents,  though,  must  be  external  to  the  project  whose  architecture  is  being  evaluated. 
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Coordinated  Use  of  QAW  and  ATAM 
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Impact 

A  QAW  and  ATAM-based  evaluation  have  been  successfully 
integrated  into  an  RFP/contract  for  a  major  DoD  acquisition. 

The  approach  and  RFP/contract  language  were  approved  by  an 
independent  assessment  team  and  the  CLIP  contracting  officer. 

Based  on  the  CLIP  experience,  we  have  developed 
“ Guidance  for  Reducing  Software  Acquisition  Risk  through 
Architecture  Evaluation 

This  guidance  is  available  to  DoD  programs  that  want  to  promote 
architecture-centric  development  and  proactively  perform 
software  architecture  evaluation  in  their  system  acquisition. 

The  architecture  evaluation  approach  and  corresponding  contract 
language  and  software  deliverables  will  be  described  in  a  set  of 
SEI  Technical  Notes. 


©  2005  by  Carnegie  Mellon  University 


page  19 


